查看原文
其他

你的服务还OK么?

林湾村龙猫 Java之间 2019-05-13

点击上方Java之间”,选择“置顶或者星标”

你关注的就是我关心的!

作者:林湾村龙猫

微信公众号:林湾村龙猫(rudy_tan_home)

“哎哎,XX,很多客服反馈这个业务挂了怎么回事,赶紧看看。” 正在安安静静写代码的你心头一颤,出问题了。赶紧打开业务链接看看,真出问题了,怎么办,怎么查问题?一脸闷逼。

据说 现代医学始于听诊器的发明,医生凭借该物 收集放大从各个器官发出的声音以诊断问题。

我一直喜欢把我们做后台做业务的,称之为 在快速飞行的飞机上修零件。边飞边升级。。在飞机上有各种各样的仪表盘指示着各个模块的运行情况。如果没有这些,估计只有等到飞机坠毁的时候才知道出问题了,这个时候为时已晚。

飞机如此,我们的业务与服务又该有什么样的 仪表盘/听诊器呢?

这是我这篇文章想说的,当我们自己的后台服务及业务运行情况生病出问题了,怎么做好服务/业务的仪表盘- 业务监控告警。

意义与想要达到的效果

没有一个系统是100%没有问题的,那么我们要保证我们的业务和服务的可靠性。我们希望达到如下的效果:

  • 我们要能够及时的发现问题(先于客户/老板发现问题)。

  • 不想每天半夜爬起来处理不知道怎么来的问题(有一些事情准备)。

  • 出了问题,能够帮助我们,快速定位问题。

需要想清楚的问题

为了达到这样的效果,我不得不思考我们需要解决的问题和点。

1、什么是我们需要关心的点

只有了解你的业务,才能做出更好的系统设计。

通常来说,只有了解你的业务,你才知道哪些点应该是你重点关注的、哪些点是容易根据业务进展而做扩展的。一般来讲,一个业务服务应该关注的点,我觉得如下:

  • 机器系统资源(CPU/内存/网络/磁盘)、CDN等。

  • 如果是JAVA,需要关注JVM虚拟机运行情况。

  • 接口的调用量、耗时情况、错误异常等。

  • 具体业务节点(如注册、开户、交易、付款等等流程)

  • 具体运营节点(运营渠道来源统计、场景等)

2、怎么定义异常情况

通常来讲,如果没有什么特殊处理,今天同一时间与昨天同一时间的监控数值应该会基本一致。基于这样一个依据,我们可以做一些比较以发现问题。

  • 同比:当前时间跟昨天同一时刻进行比较,是上升还是下降。 用于突然的掉底或上升问题发现。

  • 环比:当前一段时间与前一段时间比较,一般用得比较少。

  • 七日平均值:当前时间与前七天同一时刻平均值进行同比。减少某天波动带来的影响。

3、什么时候发现异常情况

通常来讲,做一件事情, 投入的成本、 时效性、 准确性三者之间同时达到比较好的状态是一件及其困难的事情。这个时候我们希望投入的成本带来最大化的,部分作出妥协。

  • 实时监控处理:强调实时性,针对关键节点、存在少量数据不一致或丢失情况。

  • 隔日处理:有充足的资源、全量节点、数据准确、利用大数据能力。

4、异常的程度如何

如同一个人生病一样,可能只是一个小感冒,也有可能得了大病。我们不可能为了小感冒而住院,也不可能忽略了大病的存在。因此我们需要给异常分级处理。

  • 忽略:一些可以忽略的数据波动,影响比较小的、不紧急的情况。

  • 通知:提醒负责人该关注一下这里的问题,视情况而处理,比如钱不够了加钱,交易上升了等等。

  • 告警:出现比较大的问题了,需要安排人力紧急排查了。

5、怎么通知

跟上面异常程度相对应的,我们需要有不同的告警方式通知关注者,既减少骚扰有能及时发现问题。紧急程度依次是:短信/电话 > IM(微信钉钉等) > 数据图表

  • 短信/电话:对应异常告警等级。

  • IM:对应异常通知等级。

  • 数据图表:对应异常忽略/通知等级。

6、怎么做到是告警而非骚扰

这一点,我觉得把握住两点就可以:

  • 以人为本:人都是懒惰的,做到高内聚低耦合,暴露给外部是简单的。

  • 精细化处理(细节):精细化处理某些节点。根据不同场景采取不同策略。

如何去做的问题

我大概分3个阶段去说明一下

1、简单处理

当业务或系统刚开始做的时候,这个时候也需要监控告警,但是暂时又没有这么大的人力去做,这个时候我们可以简单处理一下,对几个关键节点根据数据库记录,做隔日统计和分析,先做一个。完成从0到1的过程。

  • 定时扫描关键节点数据库统计同比。

  • 统一阀值波动告警。

2、业务数据计算统计模块

当业务或系统成长到一定阶段,这个时候简单的全量扫表会出现各种问题,比如性能耗时等等,这个时候,我们可以将监控告警独立成单独的模块做处理。

  • 实时统计自己若干节点,保存到统计数据库(5分钟粒度)

  • 根据今明两天数据做同比。

  • 分不同紧急程度不同阀值实时告警(可配置中心配置)

  • 统计数据库通过otter同步到大数据做数据分析和报表。

3、日志收集分析系统

随着业务或系统的发展,可能不止一个业务或系统需要这样的监控告警的能力,这个时候,我们可以将监控告警做成一个系统,可供多个业务或系统使用。抽象成业务关注的节点通过行为日志上报,大数据中心做数据分析和存储。

  • 定义需要统计的节点的维度、度量、原始数据留存时间。

  • 业务上报日志客户端。

  • 明细日志数据临时存储、通过otter或kafka同步到大数据中心。

  • 大数据中心根据节点、统计维度、度量、统计时间做交叉数据统计。

  • 根据交叉数据做实时监控告警。

  • 根据明细数据做全量数据报表。

效果

针对一些比较关注的点,当出现比较大的下滑或上升的时候就可以人工介入。

这个时候,我们收到了告警,有时候很难一下子发现问题,这个时候曲线图去查问题就要方便很多。

最后,希望看到最后的你有所收获。>-<

最近热文阅读:

1、你的简历到底问题在哪?

2、分布式协调服务的自我修养

3、讲讲亿级PV的负载均衡架构!

4、Spring Boot中如何干掉if else

5、一篇读懂聚集索引、非聚集索引、覆盖索引的工作原理!

6、Maven 的这 7 个问题你思考过没有?

7、最易懂的数据库异地多活方案

8、分布式事务常见的5种解决方案

关注公众号,你想要的Java都在这里!

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存